All Categories :
Servers
Chapter 22
Company Practices/Procedures Manuals
CONTENTS
Every organization, large or small, has hundreds of documents
and other pieces of data that can be put on an Intranet for its
customers. One major category of these is your company's practices
and procedure manuals. Whether you have a formalized program of
written standards for doing things or operate ad hoc much
of the time, you undoubtedly have some documents that give instructions
about how things are done. These instructions can range from the
most mundane, such as how employees work or how vacation and sick
time are recorded and reported, to the practical, such as company
purchasing procedures, to the sublime, as in overall organizational
policy statements on such large matters as corporate goals, employee
diversity, or safety in the workplace. In this chapter, you learn
how to integrate the information and tools presented earlier in
this book and to make many of these documents accessible on your
Practices/Procedures Intranet.
You also learn in this chapter about the use of graphical data
and HTML imagemaps for your Intranet. This same general
process of integrating the material from the rest of this book
applies in the next several chapters.
If your company uses computers to create documents, you already
have the foundation of your company's Practices/Procedures Intranet
built. Your first task is identifying and locating these documents
and getting them online on your Intranet so that they are easily
accessible. You can find these documents in administration, engineering,
human resources, and other corporate departments. You can also
find them in filing cabinets.
The fact that paper copies of employee manuals, for example, are
distributed to all new employees probably means there is an electronic
original somewhere in personnel. Similarly, if your shipping/receiving
department has written procedures for handling dangerous or delicate
shipments of various kinds, in all likelihood you can find those
procedures on somebody's computer disk in a word processor file.
Although locating documents in this way might be a tedious, logistical
problem, it's still possible, and what you find will provide the
basis of your company's Practices/Procedures Intranet.
The main principles of this activity are those outlined in Chapter 3,
"The Software Tools to Build a Web," with respect to
the conversion of your legacy data for your Intranet. If
you have electronic copies of documents available, you need to
use what you learned in that chapter to move this data quickly
onto your Intranet, making it accessible to your customers via
your Web server and their browsers. When you have legacy data
that's not in plain text format, you might need to use the conversion
tools you learned about earlier. This might include using your
applications' Save As feature to convert data into easily usable
formats such as plain text. You can also use some of the other
conversion tools covered in Chapter 3.
In addition, you might eventually want to use the Microsoft Rich
Text Format (RTF) as an in-between while converting legacy data
into HTML documents for direct use on your Intranet. Also, with
more and more vendors, such as Microsoft, Frame Technologies,
and Novell, adding direct HTML capabilities to their word processors
and other packages, you can convert your legacy documents directly
to HTML with almost no effort.
As you have learned, the basic setup of Web pages containing simple,
clickable lists of available documents is quite easy. Adding a
little subject matter organization is simple, too, using hyperlinks
to create nested menu listings. In just a few minutes, you can
present a useful list of available documents to your customers.
To these ends, you should review basic HTML markup in Chapter 5,
"What You Need to Know About HTML," and in Appendix
A, "HTML and CGI Quick Reference," focusing on basic
list markup, hyperlinks to other documents, and the jump-to-spot
features of the language.
Tip |
Use your operating system's basic utilities to get a leg up on the creation of simple HTML listings of documents. One way to quickly build a file containing the names of all the files you want to serve is to use the DOS prompt command-output redirection (for example, DIR > doclist.html). This captures the directory listing into a file. You can then edit the file to strip out unneeded directory listing details, add the HTML framework, add a few headlines, and add some list markup and hyperlinks. Your new Web page is ready to be sent to a Web browser, providing access to all the listed documents with a simple mouse click.
|
As suggested in Part I, you can come back to the skeleton Web
pages containing your converted legacy documents once you have
your Practices/Procedures Intranet running. Then you can refine
them and add value by cutting in hyperlinked cross-references,
graphics, and the like.
Monthly reports, for example, can contain clickable cross-references
to other documents, statistical tables, spreadsheet data files,
images, or even earlier months' reports (all with the same kinds
of embedded links). This done, your customers can use their Web
browsers to jump from one document to another, looking for answers
to questions by following promising threads.
The more cross-references and hyperlinks you add, the more capabilities
you give to your customers. A little later, you learn about indexing
your practices/procedures documents to give your customers even
greater opportunities to locate documents and information.
Even after you have successfully converted your legacy practices/procedures
documents and created skeleton Web pages for accessing them, you
will no doubt end up with a wide variety of document and data
formats. You will probably have plain text files, word processor
files, HTML documents, spreadsheets, graphics images, data files
created by other office software applications, and others. At
first, this might seem to be a confusing mess. However, you can
confidently deal with this situation, using what you have learned
earlier in this book, to organize the data and make it available
in its native formats. After all, your purpose in building an
Intranet is to pull together just such a wide variety of information
resources and make them accessible using a single Web browser
interface. All the information about MIME data types/subtypes
and helper applications you have learned earlier in this book
will help you as you make your practices/procedures information
available.
As you recall from earlier chapters, enabling use of your word
processor, spreadsheet, and such other office software packages
as Web browser helper applications is a simple, two-step process:
- Modify the MIME map on your Intranet's Web server(s) to add
your new document types. With IIS, this information is stored
in the Windows NT Registry. Other Web servers might store the
MIME table in a configuration text file.
- Configure your customers' Web browsers to deal with the newly
defined MIME types/subtypes by defining helper applications.
Chapter 12 provides a thorough grounding
in the subject of MIME data types/subtypes. Chapters 13
through 15 deal with a variety of common
office software packages you might need to set up as Web browser
helper applications. Now that you are putting specific documents
and other data in place for real work on your Practices/Procedures
Intranet, you might want to review that material so that you have
the ticklish syntax of the MIME map and the Web browser Helpers
dialog boxes down pat. If your customers use more than one Web
browser, you need to understand the slight differences between
Mosaic, Explorer, and Netscape in this area. Figure 22.1, showing
setup of Microsoft Word as an NCSA Mosaic helper application,
will no doubt bring this all back to you.
Figure 22.1: The Mosaic Add Viewer dialog enables you to add new helpers based on MIME.
Tip |
You need to make sure the necessary helper application software packages are available to everyone on your Intranet, perhaps by setting up anonymous FTP services on your Intranet (see Chapter 9, "Adding FTP and Gopher Services") or by simply creating a shared subdirectory on the NT file server that everyone can map to from their workstation. This sort of infrastructure can save you a great deal of time that would otherwise be taken up with manual distribution of software around your Intranet. This way, if customers need a copy of a new helper application (or a new release of an old one), to download it they can click a Web page you have created with links to the applications. If you're trying to build your Intranet in phases and you don't have the time to organize it that well yet, at least add a sentence to your home page or send e-mail to everyone to mention the location of the helper applications that can be installed from the file server.
|
Once you have taken these steps, your Intranet's customers can
use their Web browsers to retrieve and view your practices/procedures
documents as necessary, regardless of their actual document format.
As needed, helper applications are fired off as documents are
accessed. For example, clicking hyperlinks pointing to Word
files opens Word to display the files on-screen; Lotus 1-2-3
spreadsheet files work the same way. Having located the necessary
document with which to answer their questions, customers are just
a few steps away from saving or printing a copy of the document,
via your Intranet, all without a trip to the personnel or engineering
department where the document might have originated. (Hey, I've
been in a large company where that would have saved a 15-minute
walk to the copy machine.)
There is virtually no limit to the kinds of information you can
use on a corporate Practices/Procedures Intranet. You have already
surveyed the legacy information you have available and put some
of it up. You have merely scratched the surface so far, so consider
a few more ideas.
Personnel and Employee Benefits Information
Your personnel department can be a gold mine for your Intranet
when it comes to supplying documents of the sort you're looking
for. I have already mentioned the idea of an overall employee
manual, but many other personnel-related documents might also
be useful:
- Employee work-related expense and travel-expense
reimbursement rules and procedures.
- Job vacancy announcements and application
procedures/requirements.
- Procedural documents on time-keeping,
health benefits claims, retirement and pensions, use of company
vehicles and other company equipment, and employee conduct.
The first two of these items suggest possibilities far beyond
mere static documents your customers can read. Simple fill-in
Web forms can be used by employees to submit their travel expenses
for reimbursement or apply for a job opening, to give a couple
of simple examples. This sort of thing can turn your Practices/Procedures
Intranet into something interactive, something that does something.
Each of these items can be accomplished through simple CGI or
ISAPI applications that take the information customers enter into
fill-in forms and pass it via e-mail to the appropriate employees
for processing.
Although some security issues are involved in forms information
processing (see Chapter 10, "Intranet
Security in Windows NT"), you can implement this sort of
thing quite easily. Employees won't have to deal with paper forms
or spend work time for their pickup and delivery. Instead, customers'
requests for expense reimbursements or job applications are sent
when they click the Submit button in their Web browser, all without
any trips to the photocopy machine or interoffice mail delivery.
Tip |
A potentially valuable Practices/Procedures Intranet resource in the personnel area might be an interactive pension calculator. Your ordinary pension benefits information Web page would include static information about the rules of eligibility and the mathematical formula for computing pension benefit amounts. Based on an HTML fill-in form and CGI script, such a calculator would enable employees to interactively enter their salary and years-of-service information and get back a pension estimate. Such a tool, easily implemented on your Intranet, can help an employee with retirement decisions, making multiple what-if-I-worked-just-one-more-year kinds of calculations without requiring them to take time away from their desk to ask for the same calculations from a human resources specialist. Furthermore, confidentiality is preserved.
|
Other Corporate Department Information
You can easily extend these ideas to other departments and activities
in your organization. Here's a long, but by no means complete,
list of possible procedural documents:
- Rules and instructions for telephone,
fax machine, and copy machine use. I know my machine can do multipage,
multidocument, double-sided, collated, stapled copies, but I can
never remember how it works when I need it.
- Hard disk backup procedures.
- Precautions for network virus software,
and how to install and use anti-virus software.
- Purchasing and contracting procedures.
- Equipment repair procedures.
- On-the-job safety rules and regulations.
- Building and grounds use and maintenance
rules.
- Physical plant security procedures.
- Parking and traffic regulations.
- Procedures for operating manufacturing
and other machinery.
- Laboratory procedures.
- Material Safety Data Sheets (MSDS) for
chemicals and other potentially dangerous substances being used.
- Procedures for handling dangerous materials
and dealing with spills or releases of them.
- Property-pass rules for employees and
vendors taking company-owned equipment off site.
You can probably come up with an equally long list of other documents
that fit well here. Where appropriate, fill-in forms enable customers
to use their Web browsers to perform job functions, such as recording
time off, ordering supplies, or requesting equipment repairs.
Figure 22.2 shows the simple vacation form you saw back in Chapter 5.
This form, vacation.htm on
the CD-ROM, could be easily adapted into an order-entry form for
supplies or equipment. Depending on how elaborate you want to
get, your CGI back-end script for the order form, or one like
it, can e-mail the customer's order to data entry personnel in
your Purchasing Department for hand-entry into your Purchasing
system. It can also actually place the order into your corporate
purchasing database system for processing, untouched by human
hands. Again, there are security issues here, explained in Chapter 10,
that you need to consider to ensure accountability in the area
of purchasing.
Figure 22.2: The vacation form, useful in its own right, could be easily adapted to an order form for supplies.
Similar forms, using HTML menus, radio buttons, and checkboxes,
can be used for ordering everyday office supplies. Your CGI or
ISAPI applications for all these kinds of forms can be pretty
much the same script, with built-in options for sending the output
of certain forms in one direction and directing others elsewhere.
You can find basic e-mail scripts you can modify to meet your
needs in just about every book you find on setting up Web services;
you probably already have one or more of them. The Blat program
on the CD-ROM with this book can be used to mail form data to
a predetermined e-mail address for processing.
What You Need to Develop Web Applications
|
If you have heard about CGI from the UNIX world or from the early days of the Web, you might be wondering why I keep saying "CGI or ISAPI." As discussed in Chapters 19 and 20, ISAPI is a new kid on the block that uses RAM for interprocess communication between the server and the application, as opposed to the more disk-based approach of CGI. The goal of ISAPI is to run Web applications several times faster than is possible with CGI.
ISAPI was recently invented by Process Software and Microsoft and is available in both Purveyor and IIS. It is catching on, and many other Web servers are also offering ISAPI. If you're a Webmaster who is being asked to write Web applications, you also need to know that Microsoft Visual C++ version 4.1 now includes an ISAPI application wizard. All you have to do is click a few buttons and you get a DLL framework that works. You can then add extra functionality to complete the design. The Data Access Objects in Visual C++ might help you write the code that saves the form data to an ODBC database.
A CGI alternative that many claim is easier to develop (if you don't know C++, this is probably true) is Perl. Perl for Windows NT is on the CD-ROM. Perl scripts run quite a bit slower than ISAPI applications, but if your Intranet is not high traffic and your time to accomplish to the task is squeezed, you should definitely consider Perl. (Perl is also available as an ISAPI DLL.)
Chapter 19 lists other alternatives that might work without having to learn programming. If those tools don't work for you, be prepared for a learning curve if you have to write Web programs yourself.
|
You're probably thinking this chapter has gotten ahead of itself.
How will your customers locate answers to questions or locate
specific documents? Surely they won't just have long on-screen
lists of document names they have to browse through? Subject-oriented
menus aren't always a big help either. As with the conversion
of your legacy data, the answers to these questions take you back
to material covered earlier in the book. In Chapter 21,
"Indexing Your Intranet with WAIS," you learned about
a variety of powerful tools for indexing data on your Intranet
and, equally important, flexible tools for searching and retrieving
Intranet data from the indexes created by them.
The ability to search for relatively complex text strings is an
important feature of your Practices/Procedures Intranet. Similarly,
keyword searches with Boolean capabilities are important also.
Customers might not know exactly what they're looking for, and
even being able to view document names might not be enough. Text-string
and keyword searches become critical to customer searches for
information. Note that the database here is one built with an
indexing tool, such as WAIS or Excite. (See Chapter 21.)
Depending on the extent and nature of your library of practices/procedures
documents (and other documents on your Intranet), you might also
want to look at the Web-related relational database tools described
in Chapter 16, "Linking Databases
to the Web." This is particularly true because these packages
are being extended to include many different kinds of data. The
ability to create Web fill-in forms that interface with database
engines via CGI scripts (or other means) enhances your Intranet
and its capability of serving its customers.
Even if you have a preexisting full-text or relational database,
hope isn't lost. Unless it's locked up without standard capabilities,
you can just dump the data out to plain text files. As long as
the data has an identifiable format, it can be run through a tool
like WAIS, making it accessible via your Web browsers using fill-in
forms. This enables you to continue to use the data you have accumulated
in your application, and at the same time it frees you of proprietary
data formats. With the outstanding capabilities of these search
engines, you might find search-and-retrieval performance better
than you had with your custom database-not to mention that nice,
user-friendly Web interface.
The HTML imagemap capability can be an important part of
your Practices/Procedures Intranet, adding interactive features
to otherwise static documents. Imagemaps are graphical images
embedded in Web pages that have hot regions marked
off. Clicking such a hot region causes a predefined hyperlink
to be accessed, taking the customer to another document or Web
page. Clicking another hot region in the same image activates
a different hyperlink, a third hot region, another hyperlink,
and so on.
You can find imagemaps on many Web pages, including the Netscape
home page, shown in Figure 22.3. The image in the top center of
the page is a clickable imagemap, with six hot regions defined
(Netscape Destinations, Company & Products, and so on). Moving
your mouse cursor into one of those image areas causes the cursor
to change from the standard arrow cursor to a pointing finger
(not shown in this screen shot), giving you a tip-off that the
image is an imagemap. The status bar at the bottom of Figure 22.3
indicates the hyperlinked HTML page pointed to by the cursor in
the imagemap. Just click any of the regions to access the underlying
hyperlink. Not all Web page imagemaps are as well-defined as this
one, with clear delineation, but all work the same way. You should
review Chapter 5 and Appendix A, or your
other HTML documentation, for information on creating and using
imagemaps.
Figure 22.3: The Netscape home page uses many clickable imagemaps.
For creating your own imagemaps, try Todd C. Wilson's Map This!
software package, available on the CD-ROM. A sample Map This!
session is shown in Figure 22.4. The package works by loading
the graphics image, after which you select rectangles, circles,
or polygons in the image for your hot spots. Once you have done
that, you can use your mouse to drag your hot spots to size, and
Map This! generates the setup file to create the imagemap. In
this screen shot, you can see that the mouse currently lies within
a polygon region referring to mountain.htm.
Once your hot spot is selected, Map This! prompts for the URL
of the underlying hyperlink. Continue to define hot spots in your
image, and then save it when you're done. Map This! creates the
necessary imagemap files for your Intranet.
Figure 22.4: Using the Map This! sample imagemap.
Returning from the Map This! digression, let's continue the discussion
of graphics imagemaps for your Practices/Procedures Intranet.
Following are some practical ideas for your Intranet.
Graphics Campus Map/Phone Book
If your organization occupies a large campus or building complex,
you might want to help your customers navigate around the place
via your Intranet, as well as looking for employee locations.
The United States National Aeronautics and Space Administration's
Johnson Space Center in Houston, Texas, maintains such a service
for NASA employees and visitors, and it is accessible on the World
Wide Web. They use a large graphics map of the Space Center campus.
The map is useful in itself, because it shows where building,
roads, parking lots, and the like are located. Both visitors to
and employees of large organizations like NASA can use locator
maps to find their way around, and more and more organizations
are setting up such interactive, wherever-your-cursor-is-there-you-are
maps on their Web servers.
In addition to the obvious value of such a map, the image has
additional value because it's an imagemap. It provides direct,
hyperlinked, Web browser access to a great deal of additional
information about the Space Center. Clicking any building
on the map, for example, takes you to a Web page specific to that
building. On the building's Web pages, you see a photo of the
building (good for helping the visitor identify the building),
along with information about activities and NASA organizations
in that building. Many of the buildings' Web pages accessible
from the imagemap contain photos or other graphical images of
building-related activities or facilities.
But wait, there's more! On each one of these NASA JSC building
Web pages is a hyperlink labeled "Click here for building
occupants." Selecting the hyperlink brings up a scrollable
on-screen telephone directory for the people in that building.
From there, the Web browser's Find feature (in Mosaic: File |
Find in Current; in Explorer and Netscape: Edit | Find) can be
used to locate an individual's name in the directory.
Blueprints, Engineering Drawings, and CAD Drawings
As the NASA imagemap example shows, there are many ways you can
implement this tool on your own Practices/Procedures Intranet
and many services you can provide with it. Campus maps like the
NASA map can contain links to individual building imagemaps, with
the individual maps further zoomable to show individual floors
or even individual rooms. Your building services department might
have imagemaps containing building blueprints-showing electrical,
HVAC, and plumbing infrastructure-for use in building repairs
or other service. Engineering drawings of industrial equipment
or company products can be made available in the same way, with
imagemap hot regions allowing for enlargements of individual portions
of the drawings. Even your computer-aided-design (CAD) drawings
can be turned into imagemaps.
Getting your paper blueprints or engineering drawings into electronic
format might require a scanner, so be sure to save your scanned
drawings in GIF or JPEG format, if possible. Many scanners save
TIFF files, and Paint Shop Pro, available on the CD-ROM, can convert
from TIFF to GIF. If you already have electronic CAD drawings
available, you need to see whether your CAD software can export
your drawings to one of the standard, Web-supported image formats,
such as GIF, JPEG, PostScript, or Adobe Portable Document Format
(PDF). You might find that your particular CAD package's image
format is supported directly by Paint Shop Pro (or some other
graphics utility program), and that you can turn your CAD drawings
into a standard format for your Intranet. If all else fails, just
search Yahoo (www.yahoo.com)
for other graphics programs until you find one that runs on Windows
and can handle your file format.
Along these lines (hmmm, no pun intended), you need to look at
the FAQ document for the Usenet newsgroup comp.lsi.cad,
where you can find descriptions of a wide variety of free and
commercial CAD-related software that might be of use, especially
if you're using an older CAD package. Possibilities include software
to convert your existing CAD drawings to new formats, including
those supported by Web browsers. You can find this at http://www.cis.ohio-state.edu/hypertext/faq/usenet/lsi-cad-faq/top.html.
Your Practices/Procedures Intranet need not be limited to blueprints
and building maps. One idea is a schematic diagram for an electrical
lock-out device (a device for preventing use of defective electrical
equipment or equipment under repair). If you have electricians
in your company, this and other procedural standards documents
can be Web-accessible with little work on your part. Although
your graphics images can be in any format supported by your Web
browsers, diagrams can be created in the Adobe Portable Document
Format (PDF) and then displayed in the Adobe Acrobat Reader as
a helper application through the browser. Acrobat Reader is free
software you can download from Adobe's Web site, http://www.adobe.com/.
The package is available for Windows, DOS, Macintosh, and several
UNIX systems. You can also find a new PDF reader for Windows 95/NT,
Adobe Amber, which was in prerelease when this chapter was written.
Tip |
You need to define Adobe Acrobat Reader or Amber as a Web Browser helper application before you can view PDF files found on Web pages. See Chapter 13, "Word Processing on the Web," for details on setting up helper applications.
|
Note |
In late 1995, Adobe Systems acquired Frame Technologies, makers of the FrameMaker desktop publishing package. It seems logical to expect that Frame's products might incorporate direct support for Adobe PDF documents in the future. The no-cost FrameReader package can be set up as a read-only helper application for viewing native FrameMaker documents. In addition, Version 5 of FrameMaker includes direct HTML support for creating, saving, and viewing Web documents. Everything that rises must converge.
|
Yet another example of the sort of document you can place on your
Practices/Procedures Intranet is a decision-making flowchart.
Flowcharts can be applied to electrical devices in many endeavors,
including computer programming, and you can surely find uses for
them on your Intranet. As with the preceding imagemap example,
you can explode portions of such flowcharts to reveal underlying
details of the process.
You can see how you can make wide use of graphics images and HTML
imagemaps on your Practices/Procedures Intranet. Web browsers'
ease of use together with your graphics presentations can add
substantial value to your overall Intranet. Having these sorts
of documents and graphics available helps your customers meet
their own job needs. This is particularly helpful because many
of these kinds of documents are accessed only rarely. Having them
immediately accessible saves the time that would otherwise be
used in locating them and ensuring that the located copy is a
current version.
This chapter dealt with the use of Web and Web-related technology
to create a Practices/Procedures Intranet, incorporating much
of what you have learned from the rest of this book. The chapter
has focused on organizational documents and other information
that spells out how your company does things. Large or small,
every organization has standard operating procedures for many
activities, just a few of which have been listed in this chapter.
Documentation of those practices and procedures is a rich source
of data for your Intranet, and you can easily put it at your customers'
fingertips. Here's what you have done in this chapter:
- Considered the existing electronic practices/procedures
information available for your Intranet.
- Determined the form(s) of that information.
- Learned how to put that information together
so it's accessible to customers using a Web browser, putting what
you have learned about MIME data types/subtypes and Web browser
helper applications to work.
- Put what you have learned about Intranet
document indexing to work to enable search and retrieval of this
information, also using Web browsers.
- Surveyed a wide range of possible documents
and other data for your Practices/Procedures Intranet.
- Used graphics images and HTML imagemaps
to incorporate new special features in your Intranet.
The next chapter covers Intranet Help Desk applications. As with
this chapter, the next one provides concrete examples of how you
can integrate what you have learned in this book into useful and
valuable features for your Intranet.

Contact
reference@developer.com with questions or comments.
Copyright 1998
EarthWeb Inc., All rights reserved.
PLEASE READ THE ACCEPTABLE USAGE STATEMENT.
Copyright 1998 Macmillan Computer Publishing. All rights reserved.